i know you have been working on a plugin interface for the language. that should be unrelated to the changes of the libsclang interface, as i've only dealt with the interface, how to use libsclang.

Not precisely. The plugin interface also modifies the headers affected by this patch, in order to extract a minimal needed subset of API. But that means only an inconvenience and is no big deal to solve, so never mind.

i'm not sure what's the best way to incorporate QtCollider::LangClient, but maybe we can simply provide a factory function which returns a TerminalClient *, which could be a QtCollider::LangClient instance

Sounds good!

fwiw, LanguageClient was meant to be an abstract public interface and should be returned by the factory function, unless it's missing functionality?

fwiw, LanguageClient was meant to be an abstract public interface and should be returned by the factory function, unless it's missing functionality?

Both LanguageClient and TerminalClient are useful publicly: the latter has additional public interface to be used externally, and would have no sense as a virtual interface of LanguageClient.

jakob, which parts of SC_TerminalClient do you want to expose publicly? i suppose run or quit would probably make sense? (at least run is used in cmdLineFuncs.cpp)

also, stefan, why did you expose the symbols? afaict the methods using them could be be hidden in the implementation, so that PyrSymbol could be moved completely out of the public interface

it was meant as an optimization for often sent symbols and i think i've used them in a GUI client once. i think it would be better to hide them and keep PyrSymbol out of the public interface as you say. thanks for this patch, it was long needed ;)

looking at the code, i'd suggest to move SC_StringBuffer out of the public interface. one cannot use it without compiling the related source file, but it is trivial to use the LanguageClient without ...

On 03/01/2013, at 10:23, Tim Blechmann notifications@github.com wrote:

looking at the code, i'd suggest to move SC_StringBuffer out of the public interface. one cannot use it without compiling the related source file, but it is trivial to use the LanguageClient without ...

ok, but you would need to link against libsclang anyway so no need to compile the module for users of the library, no? maybe an stl equivalent could be used instead? i wrote the string buffer only because james was reluctant to depend on the stl back then.

sk

linking to the library is one thing, exporting the symbols of the class is another (atm SC_StringBuffer is not exported). but afaict it does not look too different from a std::string or std::vector

ok, after exposing run() i think we can even move the SC_TerminalClient out of the public interface. jakob, i've changed the initialization of qtcollider a bit (moving it to the factory). could you double-check if everything is correct?